在開始前，我們先來看一個範例，關於以下的 function 你覺得可能有幾個地方可能發生錯誤呢？

function fetchItemDetail(id: number) {
  const res = await fetch(`/items/${number}`)
  return await res.json()
}

這是個很常見的 js function ，透過送 API 到 /items/:id 取得一個東西的詳細資料，那我們來看有哪些地方有可能出錯吧

function fetchItemDetail(id: number) {
  let res: Response
  try {
    res = await fetch(`/items/${id}`)
  } catch (error) {
    // 網路錯誤
    throw error
  }
  if (!res.ok) {
    // 回傳的 status code 不是 2xx
    throw new Error('response status is not 2xx')
  }
  let data
  try {
    data = await res.json()
  } catch (error) {
    // 回傳的 json 有問題
    throw error
  }
  return data
}

短短的一段程式碼就有三個可能出現的問題，為什麼會這樣呢？有兩個原因

1. js 跟 Promise 都沒有辦法明確的標出來可能會發生哪些錯誤，導致這需要依賴文件還有額外的心力處理
2. fetch API 設計時的選擇，將網路錯誤跟 response code 非 2xx 的情況分開，給了你機會處理非 2xx 的 error ，但這讓檢查 status code 變成使用的人的責任

所以 Effect 怎麼解決？

我們先來看 Effect 的型別定義

Effect<A, E, R>

一個 Effect 會有三個 generic type

• A: 這個 Effect 的回傳值，你可以當作 function 成功結束時，會回傳的值
• E: 這個 Effect 可能產生的錯誤，讓你知道哪些問題可能發生
• R: 這個 Effect 執行時需要的資源，這個我們到 dependency injection 時再來細聊

首先我們先觀注 A 跟 E ，你會發現 Effect 已經明確的標注了哪些錯誤可能發生，這些錯誤是由這個 Effect 的提供者，有可能是 effect 裡的某個 function ，或是你自己在包裝原本的程式碼變成 Effect 時標上去，提醒使用的人需要特別注意有可能會發生這些錯誤的

讓可能的錯誤被明確的標示，這是 Effect 之所以可以讓你的程式更穩健的原因之一，但還不只是這樣，等到第 8 篇：「Effect 的超級魔法：排程與錯誤重試」中，我們會展示更多，不論是 checked error 可以帶來什麼好處，以及 Effect 的更多強大的功能，還請期待，在那之前，就讓我們一步步的認識 Effect 吧，在下一篇中，我們會來介紹怎麼開始建立 Effect

Reference

• https://effect.website/docs/getting-started/why-effect/
• https://effect.website/docs/error-management/two-error-types/